Image Formats Development Considerations
Donate
Considerations for the default file image format in Kicksecure: Is ISO a required image format, or can it be substituted by RAW images?
Technical Information[edit]
- persistence:
- full persistence: When installing an operating system such as Debian to the hard drive when all changes persist this is defined here as full persistence. All actions such as package and kernel upgrades are trivially possible.
- partial persistence: For example, Debian supports persistence.conf, a
persistence volume
. Kernel upgrades might be possible but are not trivial through the normal use of the system's package manager.
- ISO read-only: ISOs are primarily a read-only format. There is no way to mount an ISO as read-write and use it normally, persistently.
- Non-alternatives: There is
growisofsor Repack Bootable ISO but these cannot be used to write an ISO to USB and use it as a fully-persistent file system.
- Non-alternatives: There is
- ISO compression:
- Is an
.isocompressed? No, the.isoformat itself does not support compression. - So how are downloadable boot images by Linux distributions usually compressed? Inside the image (usually
.isoor.img), there issquashfs.img(SquashFS), which is a compressed archive.
- Is an
- ISO image format advantages:
- Most Linux distributions provide ISO images. Therefore, many users know what to do with these.
- Non-features of ISO images:
ISO Images vs RAW Images[edit]
- Disadvantages of not providing ISO images:
- usability: Some users will be confused. [1]
- Advantages of RAW images / Advantages of deprecation of ISO images:
- lower development effort:
- Writing build scripts to create bootable ISO images has a high initial development effort.
- Faster build process.
- Even mkosi by the systemd project does not support ISO images yet due to the difficulty of creating (SecureBoot compatible) bootable ISO images. [2]
- lower development effort:
- Advantages of RAW images:
- DVD support: Only ISO images are compatible with optical media. However, DVD drives are rarely used nowadays.
- read-write support: An image written to USB can be fully persistent.
Image Compression Issue[edit]
If images are compressed (for example to .tar.gz), this causes a usability issue. At the time of writing, no image to USB writing tool could be found that natively supports compressed RAW images except balenaEtcher, which has privacy issues, see balenaEtcher. The user would have to decompress the image before flashing it, which requires an extra step and is therefore a usability issue.
This issue equally applies to ISO images as well as RAW images.
The only other solution would be using a SquashFS but that would make the image read-only after it has been booted. Maybe the SquashFS could be persistently decompressed during the first boot?
systemd feature request: add option for persistent de-compression of SquashFS during first boot
Image Encryption Issue[edit]
- unencrypted images: If just flashing a RAW image to USB, it would be unencrypted by default. In the ecosystem of Linux desktop operating systems, there is no in-place encryption that users could easily enable after the first boot. Encrypting an already installed system requires difficult sysadmin skills and booting from an external drive.
- encrypted images: Images could be encrypted by default with a public, well-known key, and later users could be told to change the password and use
cryptsetup-reencrypt.- However, this could be a security issue if users misunderstand the security properties of such an encrypted-by-default system.
- In theory, the system could boot automatically without password entry as long as the user does not change the default password.
- This approach could confuse users who do not wish to use encryption, as it would complicate data recovery (accessing the internal hard drive after booting from an external USB) and data backups.
- reputation risk: Bad security practice with a hardcoded, public, well-known key.
- maintenance load: Most likely, both an unencrypted and an encrypted image would need to be offered for download.
- usability issue: When offering both types of images (unencrypted, encrypted), users might be confused.
- potential solution: systemd feature request: option to set up full disk encryption during first boot
Future[edit]
- grml-debootstrap, the tool used to create Kicksecure based images, does not support creating encrypted images. upstream feature request: encrypted VM images support
- Porting to mkosi might be an option because it supports encryption, but Derivative-Maker has not been ported to mkosi yet.
- Does mkosi support other architectures besides
amd64such asarm64?
- Does mkosi support other architectures besides
Comparison with Others[edit]
Tails offers .img and .iso images. Tails has a ticket Stop distributing ISO images.
Goals[edit]
- The differences in the code base for Live Systems vs. Installer Systems vs. Installed Systems should be reduced as much as possible.
Live Systems vs. Installer Systems vs. Installed Systems
In my model I'd like to remove the distinction between these three concepts as much as possible: each of these three images should carry the exact same `/usr/` file system, and should be suitable to be replicated the same way.
So I want to provide a generic image for users to download. The image should be able to be flashed on an internal hard drive, a USB drive, on a server or anywhere else.Fitting Everything Together
- Installer specific code should be as minimal as possible.
Footnotes[edit]
A secure by default operating system with the latest security research in place.
At
Kicksecure we value freedom and trust, supporting Open Source and Freedom Software
2012-
2024 ENCRYPTED SUPPORT LP
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!